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Appendix A - Distinctive Primitives Which Can Be 
Specified in a Conceptual Model Using the Tool of the 
Claimed Invention Which Cannot Be Specified By The 
Prior Art Tools 

Local Transactions (Object Model) 
Purpose 

A transaction is a molecular service: that is, a service whose functionality is defined by a 
sequence of other services. The services composing a local transaction can be atomic 
(events) or molecular (transactions). 

The combination of the valuations defined in the Functional Model (which determine the 
functionality of events) with the composition mechanism of transactions result in the 
ability to completely define the functionality of services (either atomic or molecular). 
Supporting Figure(s) in our specification 

Figure 13 IN CHG-0O1.1P and CHG-001.2P ClPs 

Supporting Passages in our specification 

Page 63, line 5 

"FIG. 13 is a screenshot of the dialog box used to create one formula in a local transaction 
carried out by a composed service (single services are called events, and composed 
services arc called local transactions)." 

Page 20, line 3 

"Services can be of two types: events and transactions. Events are atomic operations 
while transactions are composed of services which can be in rum events or transactions 
Every service can have the following characteristics: name, type of service (event or 
ttansaction), service alias, remarks and a help message. Events can be of three types- new 
destroy or none of them. Events can also be shared by several classes of the project ' 
Shared events belong to all classes sharing them. Transactions have a formula that " 
expresses the composition of services." 

Page 27, line 3 

"An "event" as used in the claims means a single service and not a transaction which is 
defined as a composed or complex service (which means more than one service executes)." 

Page 39, line 1 

"The molecular unita that are the transactions have two main properties First thev 
follow an allying policy ^ ^ to ^ execution o^e involved ^Lhen 
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a failure happens during a transaction execution, the resultant state will be the initial one. 
Second, they exhibit the non-observability of intermediate states." 

Valuations (Functional Model) 
Purpose 

The functional model defines how the occurrence of events of a class change the values of 
attributes of said class. This is done by means of valuations. 

Figure(s) in our specification 

Figure 5 

Figure 15 IN CHG-001.1P and CHG-001.2P CIPs 
Passages in our specification 

Page 12, line 12 

"FIG. 5 illustrates an exemplary dialog for receiving input for the functional model." 
Page 13, line 10 

"FIG. 15 is a dialog box to enter the functional model formulas that define evaluation of 
the attribute "cause" with the "modify" event (an event is a single service). The functional 
model relates services mathematically through well-formed formulas to the values of 
attributes these services act upon." 

Page 17, line 13 

"In one implementation, the Conceptual Model is subdivided into four complementary 
models: an object model, a dynamic model, a functional model, and a presentation model." 

Page 18, line 19 

n ^^177 l 7!: ntaiy modeIS ' ** of * e object mode1 ' the *«w. the 

- * allow a design to specify 

Page 19, line 7 

"In accordance with the widely accepted object oriented conceptual modeling principles, 
the Conceptual Model is subdivided into an object model, a dynamic model andT 
fimct-onal model. Tb.ese three models, however, axe msufrlcie^^^ 
a complete apphca.on, because a complete appli cation also requires a user interface/ 
Page 26, line 29 

"One embodiment of the present invent mploys , ^ ^ ^ 

CHG-00 1 . 1 P AMEND 6/04 4 3 
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quite different with respect to these conventional approaches. In this functional model 
the semantics associated with any change of an object state is captured as a consequence 
of an event occurrence. To do this, the following information is dedaratively specified- 
how every event changes the object state depending on the arguments of the involved 
event, and the object's current state. This is called, "valuation." 1 

In particular, the functional model employs the concept of the categorization of 
valuations. Three types of valuations are defined. :push-pop, state-independent and 
dttcrete-domain based. Each type fixes the pattern of information required to define its 
functionality. 

Push-pop valuations are those whose relevant events increase or decrease the value of the 
attribute by a given quantity, or reset the attribute to a certain value. 
State-independent valuations give a new value to the attribute involved independently of 
the previous attribute's value. 

Discrete-domain valuations gi ve a value to the attributes from a limited domain based on 
the attribute's previous value. The different values of this domain model the valid 
situations that are possible for the attribute." 



Page 26, line 29 

"One embodiment of the present invention, however, employs a functional model that is 
quite different with respect to these conventional approaches. In this functional model 
the semantics associated with any change of an object state is captured as a consequence 
of an event occurrence. Basically, the functional model allows a SOSY modeler to specify 
a c ass, an attribute of that class and an event of that class and then define a mathemS 
or logical formula that defines how the attribute's value will be changed whenXs ZZT 

etcte^ 

valuation. The condition is a single math or logic formula is specified which soecifies * 
conditionwhichresultsinavalue or logical value ^ c» taaSSTcSSTrf 

T^ZT^T, of * T^" is changed *™£2t? 

atwT*;^ 

thenfillinoneo^fo^ 

rmuia or logical expressions (condjtion-action or only action) 
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T^tTT "1.™ ° {tlm atlribUte Wm be ch *** when the service is 

executed The unportant thing about this is that the user be allowed to specie 
^-^caioriogica! operation which will tod^l^^ 

and the semce of that class and then fill in a mathematical or logical expression^* 
controls what happens to the specified attribute when the sendee is JLJm^ 

valuation. Every valuation has to have a condition and action pair in the preferred 
embodiment, but m other species, only an action need be specified. The condition can be 
anyweli™ 

*vo possible condnW true or false. The action specified in the pairTany ote^l 
to^athematical^ 

tribute, sa.dnew value being of the attribute's same data type (type of data of action 
must be compatible with the type of data of Ihe attribute). XJsLhJ a^be 

matfie^^T a Boolem logical expression or a combination ofboth 

mathematical operators and Boolean logical expressions. 

Regardless of the user interface used to gather data from the user to define the valuation, 
m the functtonal mode,, all species within the genus of the invention of Z^Z 

ftinetionality. ^ ™ <« )WI«n of mfimntton requind to define its 

Push-pop valuations are those whose relevant even..,'.™. j 

«*-. by a given ouantitv, or «, J^S? a^ ^T*" «» ^ ° f 

State-independent vaiuations a™ vaiue to the ^ involved ^ 
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the previous attribute's value, 
Page 29, line 1 

^S^ZlZt^ 1 T** 10 " rf « — **■ 

receiving input for the A^cO^Z .« * " ^ for 

Page 37, line 12 

"Evaluations are formulas of the fnrm r=i u 

Action «h . Mt^dLlTTT" is *- * defining a p 

tamitions ^ ol!ject ^ y ™ ~ '( tact.ondefctn.ta 
«™pMlere are the following evaluations: of an acton a. In the 

[loan( )] be»k_count=bc*lt_<»untt-l; 
[rerurns< )] book_count-book_count-l; 

execution in s of the action considered." by ^ ob J ect after the 

Page 40, line 12 

Page 63, line 16 

^-entforeachvaHah^^of^rr ^ UOfl °» !0fwl »' of 
CHG-001. IP AMEND 6/04 
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This is the process of building the functional model portion of the Conceptual Model. 
The value change of an attribute when an event happens is known as "evaluation". 

FIG. 15 is a dialog box to enter the functional model formulas that define evaluation of the 
attribute "cause" with the -modify" event (an event is a single service). The functional 
model relates services mathematically through well-formed formulas to the values of 
attributes these services act upon. Note that at box 724, the SOSY modeler has not filled 
in an evaluation formula that could be encoded in the final code to do a calculation to 
change the value of "cause" when the modify event occurs. Instead, as seen from box 726 
the value of "cause" will be changed to whatever the value of the argument "p cause" of ' 
the event "modify" when "modify" is executed." 

Dynamic Model 
Purpose 

The dynamic model specifies the behaviour of an object in response to services triggers 
and global transactions. It encompasses: 

• The State Transition Diagram 

• The Object Interaction Diagram 

Figurefs) in our specification 

Figure 4A (State Transition Diagram) 
Figure 4B (Object Interaction Diagram) 

Figure 1 7 (State Transition Diagram) EN CHG^Ol.lP and CHG-001.2P ClPs 

Passages in our specification 
Page 13, line 17 

ZZk™I'> bating the state transitions for the 

Page 24, line 20 

stales thai danKKrias ,w 7?',. Mm t0 M •WW** sequence of 

nanges oi state. A transition has an action and, optionally, a 

CHG-00 1 . l p AMEND 6/04 4 ? 
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control condition or guard. An action is composed of a service plus a subset of its valid 

XL f? wn ^ M ° deh * aU ° f * 6m ~ marked > Ae * "-led 

with an asterisk (*). Control conditions are well formed formulas defined on object 

attributes and/or service arguments to avoid the possible nonsieterminism for a given 

action Actions might have one precondition that must be satisfied in order to accept its 

execution. A blank circle represents the state previous to existence of the object 

Transrtions that have this state as source must be composed of creation actions.' 

IZtTZ- Wpre$ent * e State deStruction of ** Tuitions 

having this state as donation must be composed of destruction actions. Intermediate 
states are represented by circles labeled with an state name. 

s^??*'w e State , tranSiti ° n sh <™ a grappa! representation of the various 

states of an object and transitions between the states." 

Page 25, line 15 

transitions are represented by solid arrows from a source state to a destination state 
The midoUe of the tuition arrow is labeled with a text displaying the action 
precondition and guards (if proceeds)." *uw«cuon, 

Page 25, line 24 

L^lT inte fi ion / iafiram Specifies interob J«* communication. Two basic 
service ll * J? ! W " °° tMire 01385 POP^on if broadcast™ the 
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accordance with one embodiment of the present invention. 

In the object interaction diagram 420, the graphical mteractions is represented by lines for 
the components of a graphical interaction. Graphical boxes, such as reader box 422, are 
declared, in this case, as special boxes that can reference objects (particular or generic) 
such as a reader. Graphical triggers are depicted using solid lines that have a text 
displaying the service to execute and the triggering condition. Components of graphical 
interactions also use solid lines. Each one has a text displaying a number of the 
interaction, and the action that will be executed. In the example, trigger 424 indicates that 
the reader punish action is to be invoke invoked when the number of books that a reader 
is currently borrowing reaches 10." 

Page 40, line 5 

"The dynamic model uses two kind of diagrams, the state transition diagram and the 
object interaction diagram. From the state transition diagram, the following are obtained" 
event preconditions, which are those formulas labeling the event transitions: the process 
definition of a class, where the template for valid object lives is fixed. From the object 
interaction diagram, two other features of an OASIS class specification are completed- 
trigger relationships and global transactions, which are those involving different objects." 

Page 64, line 17 

"FIG. 17 is one of the two graphical user interface diagrams of the dynamic model on 
which the SOSY modeler has drawn a graphic illustrating the state transitions for the 
expense" class. Each state in the state transition diagram represents a valid state for the 
object and represents one of the "valid lives" and really is one of the unseen attributes of 
the expense class. An object can only enter one of the displayed states if the 
corresponding service has been thrown to transition to it from a previous state." 

[Col. 9, lines 28-32] 

;A class can also store triggers. Each trigger may be composed of trigger target specified 
» terms of self, class or object, trigger condition, triggered action (sStocS Z o f 

oT^^ 
Page 38. line 8 

•Triggro are formula, „f the form _[_a]f alse,, »here a is the action negation This 

ferrnuta m«ns that a does no, occ™, and ^ ^ „ nol 

an achon otter ton a occurs, ten there i, no successor s«e. Tnisforces . * o2 Tor 

formula where « »ch,de in the trigjered service information anoutL dJZE. 
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book_coimt-10 [Self::punish( )] false 

^iSZ r " C " bUt m ° re for «dU. 

Self:.-punish( ) if book_count=10; 

^ence between preccndat^s and triggers comes from the feet that in triggers there is 

Presentation Model 
Purpose 

Describe user interface requi sites in an abstract way reeardlem of W a 

are to be implemented. regardless of how these requisites 

Figures) in our specification 

FIG. 20 (Filter) IN CHGMW1.1P and CHG-001.2P CIP 

Passages in our specification 
Page 13, line 20 

"FIG. , | fa a dialog box used by the SOS Y model* „ est , blish ^ p^^.,. 
Page 13, line 21 

Page 11, line 16 

— * to specify fce « SKS^T^ - *- *• 

CHG-00 1 . 1 P AMEND 6/04 
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Conceptual Model that specifies requirements for a software application. The 
Conceptual Model includes a presentation model that specifies patterns for a user 
interface of the software application. The formal specification, which also specifies the 
presentation model is validated; and the software application is then generated based on 
the validated formal specification. As a result, the generated software application includes 
instructions for handling the user interface in accordance with the patterns specified in the 
presentation model." 



Page 29, line 11 



The presentaton model is a set of pre-defined concepts that can be used to describe user 
interface requisites. These concepts arise from distilling and abstracting repetitive 
scenarios in developing the user interfaces. These abstractions of the repetitive scenarios 
are called patterns. A set of patterns is called a pattern language. 

In this sense, the presentation model is a collection of patterns designed to reflect user 

^rrr^ A Pattem " a dear de ^onofarecurreS P rob^tn 
recurrent solution ma given restricted domain and giving an initial context The 
documen ed patterns abstract the essence of the problem and the essence offce solution 

"LxTal^ 

contextanddomain-Thepattemlanguageiscomposedofapluralityofnattems The 
present invents is not limited to any particular list of pattern^e fZSj?. 
bnef description of some user interface patterns that have been found to beS 

pattern, master-detail presentation pattern and action Selection presentation pattern." 

Primitive: Service Presentation Pattern 
(currently referred to as Service Interaction Unit) 
Page 29, line 25 ' 

the service or to exit nerfbrmi™ Z , ♦ T- a f gUments ^ contams to launch 

refer to more ^ f *S °* 0ther P— that 

pattem, population se^ction Da ^T f mtr0ductlon defined selection 

Primitive: Introduction Pattern 
Page 29, line 29 
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application). In particular, edit-masks and range-values are introduced, coijstraining the 
values that can validly be input in the interface. In this manner, the user-entry errors are 
reduced. This pattern can be applied to arguments in services or to attributes in classes to 
improve data input process trough validating input arguments." 

Primitive: Defined Selection Pattern 
Page 30, line 3 

Iheint^ ^^P^^^^aset of valid values foran argument When 
the input data items are staUc, are a few, and are well known, the designer can declare bv 
enumeration a set containing such valid values. This partem is similar to those that defme 
an enumerated ^ e and an optional default value. Accordingly, the final user cTonry 
rtecu. entry from the pre-specified set, thereby reducing IL prone inpul Tor " 
example one representation of this pattern could be a Combo-Box. This partem can be 
aj*h«i to arguments m services or to attributes in classes to improve da£ input 

Primitive: Population Selection Pattern 
(currently part of the Population Interaction Unit) 
Page 30, line 11 

order cntenon, which respectively determine how objects ^ Rl^Tml^ , 
what data is displayed fDisnlav 9rn „«h u Z ( Uter Ex P«ssion), 

»pj*ycu display bet), and how objects are ordered fOr-H^ rw,~u\ -n.- 
pattern may be thought of as a SQL Select statement Jit T, t Cnteria )- TJus 

expression and order by for the ordJ^f , * llWmS ' wh<5re for flJter 

arguments in m^^tZ^^ * 
of existing objects." ^ leCt ** Cbject from a Population 

Primitive: Dependency Pattern 
Page 30, line 19 

Primitive: Status Recovery Pattern 
Page 84, line 17 

dependency patterns. »' S ims 0311 be ™odeled as an implicit set of 
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Primitive: Supplementary Information Pattern 
[Col. 15, lines 56-59] 

The supplementary information pattern handles the feedback that is provided to final 
aSSUfe CW ° r ^ *« ««* ™ Object Ltifiet) ^ 
[Col. 15, lines 63-64] 

"The supplementary information pattern j, applicable to objea-valuated arguments." 

Primitive: Argument Grouping Presentation Pattern 
[Col. 15, lines 65-67] 

Primitive: Instance Presentation Pattern 

referred to as Instance Interaction Unit) 
[Col. 16, lines 1-5] 

PrijnWv., Cl„, P,pulrt„ n Pre,*,,.,,,,,, p 

final met will be able to launch a semW . ^ °° M m 0bject U " too «* *e 

objects can also be SitiedT ""^ 10 to othe, related objects, m, 

Printitfve, Master-Detail Presentation p,^ 

(multiple detail, an™L"^tS~°, " ^ — * «"*"-' 
modeled. For example one ^,^1 C *' pk ,mU can be 

xample, one scenario tnvolves an invoice header followed by a set of 
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invoice lines related to the invoice." 



Primitive: Action Selection Pattern 
[Col. 16, lines 21-28] 



"An action selection pattern captures how the services are offered to final users following 

sheets: t ^ ^ ~ * ~ ^rr 0f 

services specified in the classes of the Conceptual Model. The user could launch services 
or queries (observations) defined in the Conceptual Model." 

Primitive: Filter Expression 
[Col. 16, lines 29-40] 

•A Filter Expression is a well-formed formula that evaluates to a Boolean tvoe ThU 

Primitive: Display Set 
[Col. 16, lines 41-44] 

•W. and faSw " ab * a " ion ° f,he «"™™ *» » SQL 
appnea in a population selection pattern." 

Primitive: Order Criterion 
[Col. 16, lines 45-50] 

An ortofritcnon ^ ^ * J" » ^^onoverth. «— object 



(Date of Deposit) 
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